Method and system of generically specifying congestion control and a voidance behavior

ABSTRACT

A method and system for controlling congestion control and avoidance behavior of a plurality of heterogeneous network processors in a network is disclosed. The network also includes at least one host processor that utilizes at least one congestion control application. The method and system include providing a plurality of generic application program interfaces (APIs). The generic APIs communicate with the congestion control application(s) and the heterogeneous network processors. The generic APIs communicate with the congestion control application(s) in the host processor(s) in a network processor independent manner, but manage the congestion control and avoidance behavior of the heterogeneous network processors in a network processor specific manner. Thus, the generic APIs allow the control application(s) to be network processor independent and to manage the congestion control and avoidance behavior of the heterogeneous network processors in the network processor specific manner.

FIELD OF THE INVENTION

The present invention relates to computer systems, and more particularlyto a method and system for providing a mechanism for allowing a host tomanage congestion control and avoidance behavior of a network processorin a scalable, flexible manner.

BACKGROUND OF THE INVENTION

Driven by increasing usage of a variety of network applications, such asthose involving the Internet, computer networks are of increasinginterest. In order to couple portions of a network together or to couplenetworks together, network processors residing in switches, routers,and/or other components are typically used. In order to adequatelycontrol the traffic through the network, the behavior of each networkprocessor is controlled to determine its actions in the event ofcongestion and to attempt to avoid congestion. Congestion occurs for aparticular network processor when the network processor may droppackets, for example because the network processor receives more packetsin a particular interval than can be queued or transmitted. Theaction(s) that a particular network processor is to take in the event ofcongestion may change depending upon the network. Thus, a networkadministrator typically desires to manage the congestion control andavoidance behavior of the network processors.

FIG. 1 depicts a block diagram of a conventional system 10 for managingcongestion control and avoidance of network processors. The system 10includes a conventional host processor 10 used by a networkadministrator and conventional network processors 30, 40, and 50. Theconventional host processor 10 typically includes a conventionalcongestion control application 22 that is developed at least in part bythe owner of the conventional system 10. The network administrator usesthe conventional congestion control application 22 to manage thecongestion control and avoidance behavior of the conventional networkprocessors 30, 40, and 50 in the conventional system 10.

The conventional network processors 30, 40, and 50 are typicallypurchased by the owner of the conventional system 10. The conventionalnetwork processors 30, 40, and 50 each includes conventional softwareand/or firmware 32, 42, and 52, respectively, that may be different. Forexample, the conventional network processors 30, 40, and 50 may includedifferent versions of a particular model of network processor from aparticular vendor and/or other model(s) of network processor that may befrom other vendors. Thus, the conventional network processors 30 and 40are depicted as having software and/or firmware 32 and 42 that aredifferent versions of a Model X network processor, while the softwareand/or firmware 52 of the conventional network processor 50 is a Model Ynetwork processor. Because the conventional network processors 30, 40,and 50 are designed to communicate with different control applications,each conventional network processor 30, 40, and 50 utilizes conventionalapplication program interfaces (APIs) 12, 14, and 16, respectively, thatare specific to the particular software and/or firmware 32, 42, and 52,respectively.

The conventional congestion control application 22 is used to manage thecongestion control and avoidance behavior of the conventional networkprocessors 30, 40, and 50, respectively. The conventional congestioncontrol application 22 thus includes a corresponding set of conventionalbehaviors 24, 26, and 28 for each set of the conventional APIs 12, 14,and 16, respectively. The conventional APIs 12, 14, and 16 are designedto communicate with the conventional behaviors 32, 42, and 52,respectively. The conventional APIs 12, 14, and 16 are also used tocontrol the corresponding software and/or firmware 32, 42, and 52,respectively. Thus, using the conventional behaviors 24, 26, and 28corresponding to the conventional APIs 12, 14, and 16, respectively, theconventional congestion control application 22 can control thecongestion control and avoidance behavior of each of the conventionalnetwork processors 30, 40, and 50, respectively.

Although the conventional system 10 functions, one of ordinary skill inthe art will readily recognize that the conventional system is difficultto scale. The conventional network processors 30, 40, and 50 aretypically heterogeneous in nature. Because the conventional networkprocessors 30, 40, and 50 are heterogeneous, the conventional networkprocessors may include different versions of a particular model ofnetwork processor and/or different models of network processor. Inaddition, the congestion control and avoidance behavior of eachconventional network processor 30, 40, and 50 may differ widely. Thus,the software and/or firmware 32, 42, and 52 of different networkprocessors typically differ. The APIs 12, 14, and 16 thus also differ.Consequently, the corresponding behaviors 24, 26, and 28 of theconventional congestion control application 22 are distinct. One ofordinary skill in the art will also readily recognize that theconventional system 10 may actually include a large number of networkprocessors. Consequently, the number of conventional APIs 12, 14, and 16with which the conventional congestion control application 22 must becompatible may be large. As a result, the number of distinctconventional behaviors used by the conventional host processor 20 anddeveloped by the owner of the conventional system 10, such as theconventional behaviors 24, 26, and 28, may be large. As a result, thecongestion control application 22 may be complex and include anamalgamation of a variety of behaviors, one for each model and/orversion of conventional network processor. It may thus be difficult toincorporate new network processors, which may have software and/orfirmware and thus APIs not previously supported. The conventional system10 is, therefore, difficult to scale. Because of difficulties inincorporating new software and/or firmware and their corresponding APIs,evolving the conventional congestion control application 22 and,therefore, the conventional system 10 to utilize improved networkprocessors may be problematic. Furthermore, because supporting a varietyof conventional behaviors 24, 26, and 28 makes the conventionalcongestion control application 22 more complex, the conventional system10 may be subject to higher maintenance costs.

Accordingly, what is needed is a system and method for allowing a hostto control congestion control and avoidance behavior of a networkprocessor in a scalable, flexible manner. The present inventionaddresses such a need.

SUMMARY OF THE INVENTION

The present invention provides a method and system for controllingcongestion control and avoidance behavior of a plurality ofheterogeneous network processors in a network. The network also includesat least one host processor that utilizes at least one congestioncontrol application. The method and system comprise providing aplurality of generic application program interfaces (APIs). The genericAPIs communicate with the congestion control application(s) and theheterogeneous network processors. The generic APIs communicate with thecongestion control application(s) in a network processor independentmanner, but manage the congestion control and avoidance behavior of theheterogeneous network processors in a network processor specific manner.Thus, the generic APIs allow the congestion control application(s) to benetwork processor independent and to manage the congestion control andavoidance behavior of the heterogeneous network processors in thenetwork processor specific manner.

According to the system and method disclosed herein, the presentinvention provides a generic mechanism for managing the congestioncontrol and avoidance behavior. As a result, a customer need notmaintain a congestion control application having different sets of APIfor different types (e.g. models and/or versions) of network processors.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a conventional system for managing congestionavoidance and control behavior of network processors.

FIG. 2 is a diagram of one embodiment of a system in accordance with thepresent invention for managing congestion control and avoidance behaviorof network processors.

FIG. 3 is a high-level flow chart depicting one embodiment of a methodin accordance with the present invention for providing a mechanism inaccordance with the present invention for managing congestion controland avoidance behavior of network processors.

FIG. 4 is a block diagram depicting one embodiment of a networkprocessor indicating locations in the network processor in which thesystem in accordance with the present invention might manage congestioncontrol and avoidance behavior.

FIG. 5 is high-level flow chart of one embodiment of a method inaccordance with the present invention for using a mechanism inaccordance with the present invention for managing congestion controland avoidance behavior of network processors.

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to an improvement in computer system. Thefollowing description is presented to enable one of ordinary skill inthe art to make and use the invention and is provided in the context ofa patent application and its requirements. Various modifications to thepreferred embodiment will be readily apparent to those skilled in theart and the generic principles herein may be applied to otherembodiments. Thus, the present invention is not intended to be limitedto the embodiment shown, but is to be accorded the widest scopeconsistent with the principles and features described herein.

The present invention provides a method and system for controllingcongestion control and avoidance behavior of a plurality ofheterogeneous network processors in a network. The network also includesat least one host processor that utilizes at least one congestioncontrol application. The method and system comprise providing aplurality of generic application program interfaces (APIs). The genericAPIs communicate with the congestion control application(s) and theheterogeneous network processors. The generic APIs communicate with thecongestion control application(s) in a network processor independentmanner, but manage the congestion control and avoidance behavior of theheterogeneous network processors in a network processor specific manner.Thus, the generic APIs allow the congestion control application(s) to benetwork processor independent and to manage the congestion control andavoidance behavior of the heterogeneous network processors in thenetwork processor specific manner.

The present invention will be described in terms of a particularcomputer system, a particular network processor, and certain APIs.However, one of ordinary skill in the art will readily recognize thatthis method and system will operate effectively for other computersystem and network processors, as well as additional and/or other APIs.The present invention is also described in the context of a networkincluding specific components and a particular number of components.However, one of ordinary skill in the art will readily recognize thatthe present invention is consistent with other networks containing otherand/or additional components as well as another number of components.The present invention is also described in the context of congestioncontrol and avoidance behavior. One of ordinary skill in the art willreadily recognize that the term congestion control and avoidance denotescongestion control and/or avoidance.

To more particularly illustrate the method and system in accordance withthe present invention, refer now to FIG. 2, depicting one embodiment ofa system 100 in accordance with the present invention for managingcongestion control and avoidance behavior of network processors. Thesystem 100 is depicted as including a host processor 110 and networkprocessors 120, 130, and 140. The host processor 110 includes acongestion control application 112. The network processors 120, 130, and140 include congestion control software and/or firmware 122, 132, and142, respectively. However, one of ordinary skill in the art willreadily recognize that the generic APIs 150 are of particular utility.In addition, the generic APIs 150 are depicted as a separate entity.However, one of ordinary skill in the art will readily recognize thatthe host processor 110 and network processors 120, 130, and 140 utilizethe generic APIs 150 for communication and control.

The network processors 120, 130, and 140 are capable of beingheterogeneous. Thus, the network processors 120, 130, and 140 may havehardware, software, and/or firmware for congestion control that differsignificantly. For example, as depicted in FIG. 2, the software and/orfirmware 122 for the network processor 120 is Model X, Version 1.0. Incontrast, the network processor 130 includes software and/or firmware132 that is Model X, Version 2.0. The network processor 140 is acompletely different model, having software and/or firmware 142 that isModel Y, Version 1.0. Other network processors (not shown) havingdifferent models and/or versions may also be included. Because they areheterogeneous, in the absence of the present invention, the networkprocessors 120, 130, and 140 would each require a separate networkprocessor specific set of APIs in order to be controlled by aconventional congestion control application, such as the conventionalcongestion control application 12 depicted in FIG. 1.

Referring back to FIG. 2, the generic APIs 150 include APIs are used bythe congestion control application 112 and the network processors 120,130, and 140. In particular, the generic APIs communicate with and areused by the congestion control application 112 in a network processorindependent manner. In other words, the congestion control application112 is network processor independent. In the context of the presentapplication, a network processor independent manner means that thecongestion control application 112 need not contain knowledge of thespecific hardware, software, and/or firmware 122, 132, and 142 of any ofthe network processors 120, 130, and 140, respectively, beingcontrolled. At the same time, the congestion control application 112 canmanage the congestion avoidance and control behavior of the networkprocessors 120, 130, and 140 by managing the software and/or firmware122, 132, and 142, respectively. Because the congestion controlapplication 112 is network processor independent, the congestion controlapplication 112 can configure and/or update the network processors 120,130, and 140 without requiring specific knowledge of the hardware orsoftware and/or firmware 122, 132, and 142, respectively of theindividual network processors 120, 130, and 140, respectively.

The generic APIs 150 also communicate with and control the networkprocessors 120, 130, and 140 in a network processor specific manner. Inthe context of the present application, network processor specificincludes a knowledge of the specifics of a particular network processor,such as the hardware, software and/or firmware 122, 132, and 142, andpossibly other components used by the particular network processor 120,130, and 140, respectively. Thus, the APIs 150 allow the congestioncontrol application 112 to be network processor independent whileallowing each of the network processors 120, 130, and 140 to be controlin a network processor specific manner.

Using the system 100, and more particularly the generic APIs 150, thecongestion control application 112 can be network processor independent.Because of the use of the generic APIs, the congestion controlapplication 112 can still control the potentially heterogeneous networkprocessors 120, 130, and 140 in a network processor specific manner. Asa result, the congestion control application 112, need not include aseparate set of APIs for each type of network processor 120, 130, and140 used. The congestion control application 112 is, therefore, simpler.As a result, it is significantly simpler to scale the system 100,including adding new types of network processors. It is thus also easierto improve the performance of the system 100 by adding improved networkprocessors. In addition, the maintenance costs of the system 100 may bereduced due to the use of a simpler congestion control application 112.

FIG. 3 is a high-level flow chart depicting one embodiment of a method200 in accordance with the present invention for providing a mechanismin accordance with the present invention for managing congestion andcontrol behavior of network processors. The method 200 is described inthe context of the system 100 depicted in FIG. 2. In particular, themethod 200 may be used to determine the generic APIs 150. Referring toFIGS. 2 and 3, the congestion control application 112 can then bedeveloped in a network processor independent manner using the genericAPIs 150. Similarly, the network processors 120, 130, and 140, which maybe heterogeneous, have components such as software and/or firmware 122,132, and 142, respectively, that can be managed by the generic APIs 150in a network specific manner. The network processors 120, 130, and 140may thus be controlled in a network processor specific manner using thegeneric APIs 150.

The congestion control and avoidance behavior of network processors,such as the network processors 120, 130, and 140, is abstracted, viastep 202. Each network processor 120, 130, and 140 performs congestioncontrol and avoidance in a specific manner. Step 202 abstracts thecongestion control and avoidance behavior of network processors to amore general level. For example, step 202 includes determining thelocations at which network processor might manage congestion.

For example, FIG. 4 is a block diagram depicting a generalized view ofone embodiment of a network processor 160 indicating locations in thenetwork processor in which the system in accordance with the presentinvention might manage congestion control and avoidance behavior.Referring to FIGS. 2-4, any of the network processors 120, 130, and 140might be represented by the network processor 160. The network processor160 is obtained by abstracting the congestion control and avoidancebehavior of the network processors 120, 130, and 140 in step 202. Inparticular, the network processor 160 indicates the locations in anetwork processor at which congestion control and avoidance might bemanaged. The network processor 160 thus includes an ingress side 170 andan egress side 180. The ingress side 170 includes ports 161-1 to 161-nfor the network processor 160 having n ports. Note that the egress side180 also includes ports 161-1 to 161-n. The ingress side 170 alsoincludes receive queues 162-1 to 162-n where received packets are queuedand receive flows 163-1 to 163-n. Note that although only two receiveflows 163-1 to 163-n are shown from receive queues 162-1 and 163-n,respectively, there are generally multiple flows from each set ofreceive queues 162-1 to 162-n, respectively. The egress side 180includes the scheduler queue flows 164-1 to 164-n, the scheduler queues165-1 to 165-n, the scheduler 166, the transmit queues 167-1 to 167-n,and the ports 161-1 to 161-n. Note that although only two schedulerflows 164-1 to 164-n are shown for scheduler queues 165-1 and 165-n,respectively, there are generally multiple flows to each scheduler queue165-1 to 165-n, respectively. Congestion avoidance and control behaviormight be managed at any of the ports 161-1 to 161-n (on either theingress or egress side), the receive queues 162-1 to 162-n, the receiveflows 163-1 to 163-n, the scheduler flows 164-1 to 164-n, the schedulerqueues 165-1 to 165-n, the scheduler 166, and the transmit queues 167-1to 167-n. Thus, in one embodiment of the general network processor 160,there are seven locations at which congestion control and avoidancemight be managed. However, most network processors 120, 130, and 140actually manage congestion at some of these locations. Thus, throughstep 202 of the method 200, the locations 161-1 to 161-n, 162-1 to162-n, 163-1 to 163-n, 164-1 to 164-n, 165-1 to 165-n, 166-1 to 166-n,and 167-1 to 167-n, are identified.

Other aspects of a network processor are preferably also abstracted instep 202. For example, the types of congestion control algorithms thatcould be applied at the locations 161-1 to 161-n, 162-1 to 162-n, 163-1to 163-n, 164-1 to 164-n, 165-1 to 165-n, 166-1 to 166-n, and 167-1 to167-n could also be identified in step 202. The type of algorithmapplied may depend upon the location 161-1 to 161-n, 162-1 to 162-n,163-1 to 163-n, 164-1 to 164-n, 165-1 to 165-n, 166-1 to 166-n, and167-1 to 167-n at which an algorithm is desired to be applied. Forexample, a Bandwidth Allocation Technology (BAT) algorithm (notexplicitly shwon) might control congestion at the input ports 161-1 to161-n. Packets arriving at each port 161-1 to 161-n are regarded as oneflow. The BAT algorithm computes the corresponding transmitprobabilities and discards packets accordingly. The algorithm generallyapplies only when congestion is sensed by the congestion controlhardware unit (not explicitly shown) in the network processor 160. BATcan preferably be enabled or disabled on a per port basis. Certaincongestion control algorithms operate on the receive queues 162-1 to162-n. For example, the Random Early Discard (RED) algorithm might beapplied at one or more of the receive queues 162-1 to 162-n. The REDalgorithm uses the weighted average queue length as a feedback mechanismto decide on when to drop packets. When the weighted average queuelength is between two configured thresholds, the RED algorithm typicallydrops packets depending on a calculated probability. The RED algorithmrelies on the responsive nature of the end protocols to preventcongestion. Many congestion control algorithms might operate on flows163-1 to 163-n, such as those based on DiffServ flows. A coloringalgorithm (srTCM, trTCM, BAT) first meters the flows 163-1 to 163-n. Adiscard algorithm (such as BAT) uses the metered color and dynamicallycomputed transmit probabilities to make discard decisions for each ofthe flows 163-1 to 163-n. Algorithms like Flow Random Early Discard(FRED) might also operate on the flows 163-1 to 163-n. Algorithms suchas FRED might also operate on the scheduler flows 164-1 to 164-n.Similarly, some network processors may support the operation ofalgorithms such as RED and WRED on the scheduler queues 165-1 to 1656-nand/or on the transmit queues 166-1 to 166-n. Thus, step 202 abstractsnetwork processors, such as the network processors 120, 130, and 140, inthe context of congestion control and avoidance.

The generic APIs 150 are defined using the abstraction provided, viastep 204. Thus, step 204 provides the generic APIs 150 that canpreferably manage congestion control and avoidance behavior at any ofthe locations 161-1 to 161-n, 162-1 to 162-n, 163-1 to 163-n, 164-1 to164-n, 165-1 to 165-n, 166-1 to 166-n, and 167-1 to 167-n. Furthermore,step 204 provides the APIs such that the individual network processors120, 130, and 140 can be managed at the appropriate location(s) in thenetwork processors 120, 130, and 140, respectively, corresponding to oneor more of the of the locations 161-1 to 161-n, 162-1 to 162-n, 163-1 to163-n, 164-1 to 164-n, 165-1 to 165-n, 166-1 to 166-n, and 167-1 to167-n. The generic APIs 150 provided in step 204 can also be used tocontrol other aspects of the network processors 120, 130, and 140 in anetwork processor specific manner. Furthermore, where a particularoperation is not supported by a particular network processor 120, 130,and 140, the generic APIs 150 account for this by providing a nullbehavior to the congestion control application 112.

Step 204 also provides the generic APIs 150 such that the APIs can beused with a network processor independent congestion control application112. Thus, using the method 200, the generic APIs 150 can be provided.The network processor independent congestion control application 112, aswell as the network processors 120, 130, and 140 can be developed toutilize the generic APIs 150.

In a preferred embodiment, the generic APIs 150 include at least APIsfor configuring and updating the congestion control and avoidancebehavior of each of the network processors 110, 120, and 130 in anetwork processor specific manner. The generic APIs 150 preferablyinclude APIs for enabling and disabling congestion control andbehaviors, as well as APIs for listing information relating tocongestion control and avoidance in the network and, more specifically,for the network processors 110, 120, and 130. In addition to controllingthe network processors 110, 120, and 130 in a network processor specificmanner, the APIs 150 preferably also return a null behavior for aparticular function that is not implemented by a particular networkprocessor.

The APIs of the generic APIs 150 that are used to configure and updatethe congestion avoidance and control behavior preferably determine thelocation(s) in each of the network processors 120, 130, and 140 at whichcongestion control and avoidance is to be managed. For example, asdiscussed below with respect to FIGS. 3 and 4, the configure and updateAPIs preferably indicate whether congestion control and avoidance is tobe applied at the ingress, egress, particular port(s), particularqueue(s), and particular flow(s). The configure and update APIs of thegeneric APIs 150 may also specify information used by the congestioncontrol algorithm(s) used by the network processors 120, 130, and 140.In one embodiment, the configure and control APIs may indicate thecongestion control algorithm, such as BAT or RED that is used by aparticular network processor 120, 130, or 140 one or more locations.

In a preferred embodiment, the generic APIs 150 include five APIs:configure, update, enable, disable, and list. In a preferredimplementation of the generic APIs, including the configure, update,enable, disable, and list APIs, parameters and fields are specified.Table 1 describes a preferred embodiment of the fields used. TABLE 1Field Name Field Description CBS Committed Burst Size. This is used bythe srTCM and trTCM algorithms to meter flows. cc_discard Specifies thealgorithm used to discard packets. cc_entity Indicates the point of thenetwork element where congestion control should operate (Port, Queue,Flow) cc_meter Specifies the algorithm used to meter or color flows.cc_point Indicates whether congestion control should apply at theingress entities or egress entities. WEST supports congestion controlonly at ingress entities. C_(i) Coefficient of increase for BAT flows.CIR Committed Information Rate. This is used by the srTCM and trTCMalgorithms to meter flows. D_(i) Coefficient of decrease for BAT flows.Discard Area The area containing parameters for the discard algorithm.Example of a discard algorithms is BAT. Discard Information Areacontaining the parameters of the discard algorithm that is Area chosenvia cc_discard. EBS Excess Burst Size. This is used by the srTCMalgorithm to meter flows. Error Area Size Indicates the size (in words)of the parameter area associated with error operation. Error CodeIndicates the Error code that is sent with error operation. Error QueueNumber Indicates the error queue number associated with this port. Ifdiscard error packet is set to yes, this queue will be set to 0x3F todiscard error packets. Flowid A 16 bit flow identifier value. Invoke IDA field used by the Service Requestor to correlate invocations withresponses. Length of Common Length of the Common Discard Area. This areacontains discard Discard Area information that is common across allflows, ports or queues. Length of Common Length of the Common MeterArea. This area contains meter Meter Area information that is commonacross all flows, ports or queues. Length of Discard Area Length of theDiscard Area. Length of Meter Area Length of the Meter Area. max_pMaximum probability of performing a RED drop. max_th Maximum queuethreshold for the RED algorithm. Max_(i) Maximum BAT bandwidth for flowi. Max_(i) Override This value overrides the Max_(i) values for all BATflows. Meter Area The area containing parameters for the meteringalgorithm. Examples of metering algorithms are srTCM, trTCM and BAT.min_th Minimum queue threshold for the RED algorithm. Min_(i) MinimumBAT bandwidth for flow i. Min_(i) Override This value overrides theMin_(i) values for all BAT flows. MO This is the value for meterover-ride. In some cases, the metering algorithm can be controlled on aper-flow basis. If this value is non-zero, the specified meter algorithmis to be used for this flow. Else, the cc_meter value in the header isto be used to select the metering algorithm. No: of fields updated inNumber of fields in the common discard area that are to be the commondiscard area updated No: of fields updated in Number of fields in thecommon meter area that are to be the common meter area updated No: offlows updated Number of flows whose parameters are to be updated. Thisfield is present for updating both the meter info area and the discardinfo area. No: of ports configured Number of ports for whichconfiguration parameters are specified in this packet. num_ids Number ofidentifiers that follow. The 16-bit identifiers can be port numbers,flow numbers or queue numbers - this depends on the algorithm in use.This is used for enabling, disabling and listing parameters of thevarious congestion control algorithms. If the value of this parameter iszero, then it means that parameters for all the identifiers (ports,queues or flows) for this algorithm are to be enabled/disabled/listed.Operation Class Indicates the conditions under which a response is to besent to the Service Requestor. Operation Code Indicates the operationwhose invocation is being requested. Operation Version Indicates theversion level of the operation. Parameter Area Size Indicates the size(in words) of the parameter area associated with this operation. PBSPeak Burst Size. This is a parameter used by the trTCM algorithm tometer flows. PIR Peak Information Rate. This is a parameter used by thetrTCM algorithm to meter flows. Port No: Configuration parameters forthis port number are present in the following fields. Port NumberIndicates the instance of the port type being operated upon. WESTsupports a maximum of 32 possible ports. Result Area Size Indicates thesize (in words) of the parameter area associated with result operation.rxq_num Indicates the receive queue associated with this algorithm. Thisis used for configuring queue-based congestion control mechanisms likeRED. Service Element Type Indicates the nature of service. The possiblevalues are: API- INVOKE, API-RESULT or API-ERROR. Shock Absorber ShockAbsorber constant for BAT. constant w_qlen Weighting factor forcalculating the average queue length for the RED algorithm.Some portion of the above fields are preferably used by the generic APIs150 for performing different operations, such as configuring andinvoking different types of congestion control at various points in thenetwork processor. Note, however, that an alternate embodiment might useadditional and/or other fields having other uses.

In order to utilize the generic APIs, a common four-word header (notshown) for congestion control services is preferably used. The first twowords of the header are preferably common to congestion control softwareand/or firmware 122, 132, and 142. The last two words are preferablycommon to all congestion algorithms that can be used, such as RED andDiffServ. Table 2 describes the uses of various fields in the header.However, in an alternate embodiment, another scheme including otherfields could be used. TABLE 2 Field Name Bit Word Value Remarks ServiceElement 02 . . . 03 0 0b00 API-INVOKE Type 0b01 API_RESULT 0b10API_ERROR Operation Class 6 . . . 7 0 0b00 Report results and errors0b01 Report resulst only 0b10 Report errors only 0b11 Do not reportInvoke ID 16 . . . 31 0 X Any value specified by Service RequestorOperation Version 0 . . . 3 1 0x0-0xF Value must match software levelOperation Code  4 . . . 15 1 0x0C10 IFS_Congestion_Config operationIFS_Congestion_Updata operation 0x0C11 IFS_Congestion_Enable operationIFS_Congestion_Disable operation 0x0C12 IFS_Congestion_List operation0x0C13 0x0C14 Parameter Area 16 . . . 31 1 Size in Words starting fromWord 2 Size cc_point 0 . . . 1 2 0x0 Ingress 0x1 Egress 0x2-0x3 Reservedcc_entity  8 . . . 15 2 0x0 Port 0x1 Queue 0x2 Flow 0x3-0x7 Reservedcc_meter 24 . . . 31 2 0x0 srTCM (color blind) 0x1 srTCM (color aware)0x2 trTCM (color blind) 0x3 trTCM (color aware) 0x4 BAT 0x5 NULL 0x6 . .. 0xFF User Defined cc_discard 24 . . . 31 3 0x0 BAT 0x1 RED 0x2 WRED0x3 SARED 0x4 FRED 0x5-0xFF User Defined

As its name implies, the configure API is used to allow the congestioncontrol application 112 (as utilized by a user such as a networkadministrator) to configure the congestion control and avoidancebehavior in a network processor independent manner, yet operate on thenetwork processors 120, 130, and 140 to configure the congestion controland avoidance behavior in a network processor specific manner. Note thatthe values of various parameters and fields depends upon, among otherfactors, the point at which congestion control and avoidance behavior isto be configured as well as the algorithm used. The parameters used by apreferred embodiment of the configure API are described below in Table3. TABLE 3 Parameter Name Value Remarks CC_Point Ingress The NP side atwhich congestion Egress control configuration applies. CC_Entity Port APort is specified by Port Number Queue A Queue is specified by a QueueId Flow A Flow is specified by a Flow Id CC_Meter srTCM (color Theadditional parameters that blind) srTCM is associated with are: srTCM(color Committed Information Rate (CIR), aware) Committed Burst Size(CBS), Excess Burst Size (EBS). srTCM applies to Flows only. trTCM(color The additional parameters that blind) trTCM is associated withare: trTCM (color Comitted Information Rate (CIR), aware) CommittedBurst Size (CBS), Peak Burst Size (PBS) and Peak Information Rate (PIR).trTCM applies only to Flows. BAT The additional parameters that BAT isassociated with are: Max-i, Min-i, Shock Absorber Constant, Di and Ci.BAT metering applies only to Flows. CC_Discard BAT BAT is associatedwith Max-i, Min-i, Shock Absorber Constant, Ci and Di. BAT discard isappli- cable for Ports and Flows. RED RED is associated with w_qlen,max_th, min_th, max_p. RED is applicable for Queues only. WRED Theadditional parameters SARED associated with WRED, FRED FRED and SAREDhave not been defined Vendor Specific in this invention.

The update API allows the congestion control application 112 (asutilized by a user such as a network administrator) to update thecongestion control and avoidance behavior in a network processorindependent manner, yet operate on the network processors 120, 130, and140 to update the congestion control and avoidance behavior in a networkprocessor specific manner. In a preferred embodiment, the update APIallows a bit field flag to be specified for each field. If the flag isset, the field value is sent with update service. Also in the preferredembodiment, the field ordering is consistent. Note that the values ofvarious parameters and fields depends upon, among other factors, thepoint at which congestion control and avoidance behavior is to beupdated as well as the algorithm used. The parameters used by apreferred embodiment of the update API are described below in Table 4.TABLE 4 Parameter Metering Name Algorithm Additional Parameters CC_MetersrTCM (color The modifiable parameters that blind) srTCM is associatedwith are: srTCM (color Committed Information Rate (CIR), aware)Committed Burst Size (CBS), Excess Burst Size (EBS). srTCM applies toFlows only and the parameters must be associated with a Flow Id. trTCM(color The modifiable parameters that blind) trTCM is associated withare: trTCM (color Comitted Information Rate (CIR), aware) CommittedBurst Size (CBS), Peak Burst Size (PBS) and Peak Infor- mation Rate(PIR). trTCM applies only to Flows and the parameters must be associatedwith a Flow Id. BAT The modifable parameters that BAT is associated withare: Max-i, Min-i, Shock Absorber Constant, Di and Ci. BAT meteringapplies only to Flows and the parameters must be associated with a FlowId. CC_Discard BAT The modifiable parameters that BAT is associated withare: Max-i, Min-i, Shock Absorber Constant, Ci and Di. BAT discard isappli- cable for Ports and Flows. There- fore all updates must be asso-ciated with a Port Number or a Flow Id. RED The modifable parametersthat RED is associated with are: w_qlen, max_th, min_th, max_p. RED isapplicable for Queues only. Therefore all parameters must be associatedwith a Queue Id. WRED The modifiable parameters asso- SARED ciated withWRED, FRED and SARED FRED have not been defined in this Vendor Specificinvention.

The enable API allows the congestion control application 112 (asutilized by a user such as a network administrator) to enable selectedalgorithms for congestion control and avoidance behavior in a networkprocessor independent manner, yet operate on the network processors 120,130, and 140 to enable the algorithm(s) for a particular processor's120, 130, or 140 congestion control and avoidance behavior in a networkprocessor specific manner. For example, the enable API can be used toenable specific algorithm(s) at certain ports (for the ingress and/oregress side) and/or flows. Note that the values of various parametersand fields depends upon, among other factors, the point at whichcongestion control and avoidance behavior is to be enabled as well asthe algorithm used. The parameters used by a preferred embodiment of theenable API are described below in Table 5. TABLE 5 Parameter Name ValueRemarks CC_Point Ingress The NP side at which congestion Egress controlconfiguration applies. CC_Entity Port A Port is specified by Port QueueNumber Flow A Queue is specified by a Queue Id A Flow is specified by aFlow Id Number Of 0 . . . 2¹⁶ A value of zero implies all Instancesinstances of the CC_Entity at the specified CC_Point. List of InstanceId₀ . . . A list of instances of the Instance Ids Instance Id_(n)specified CC_Entity for which the configured congestioncontrol/avoidance algorithm is required to be enabled.

The disable API allows the congestion control application 112 (asutilized by a user such as a network administrator) to deactivateselected algorithms for congestion control and avoidance behavior in anetwork processor independent manner, yet operate on the networkprocessors 120, 130, and 140 to disable the algorithm(s) for aparticular processor's 120, 130, or 140 congestion control and avoidancebehavior in a network processor specific manner. For example, the enableAPI can be used to disable specific algorithm(s) at certain ports (forthe ingress and/or egress side) and/or flows. Note that the values ofvarious parameters and fields depends upon, among other factors, thepoint at which congestion control and avoidance behavior is to bedisabled as well as the algorithm used. The parameters used by apreferred embodiment of the disable API are described below in Table 6.TABLE 6 Parameter Name Value Remarks CC_Point Ingress The NP side atwhich congestion Egress control configuration applies. CC_Entity Port APort is specified by Port Queue Number Flow A Queue is specified by aQueue Id A Flow is specified by a Flow Id Number Of 0 . . . 2¹⁶ A valueof zero implies all Instances instances of the CC_Entity at thespecified CC_Point. List of Instance Id₀ . . . A list of instances of athe Instance Ids Instance Id_(n) specified CC_Entity for which theconfigured congestion control/avoidance algorithm is required to bedisabled.

The list API allows the congestion control application 112 (as utilizedby a user such as a network administrator) to be used to view thecongestion control and avoidance information for any of the networkprocessors in a network processor independent manner. The list APIobtains this information for viewing from the network processors 120,130, and 140 in a network processor specific manner. For example, theinformation returned in response to the list API might contain meteringand discard information, the current state (enabled/disabled) for thelocation(s) of each of the network processors 120, 130, and 140 fromwhich the information is requested. Note that the values of variousparameters and fields depends upon, among other factors, the algorithmused. The parameters used by a preferred embodiment of the disable APIare described below in Table 7. TABLE 7 Parameter Name Value RemarksCC_Point Ingress The NP side at which congestion Egress controlconfiguration applies. CC_Entity Port A Port is specified by Port QueueNumber Flow A Queue is specified by a Queue Id A Flow is specified by aFlow Id Number Of 0 . . . 2¹⁶ A value of zero implies all Instancesinstances of the CC_Entity at the specified CC_Point. List of InstanceId₀ . . . A list of instances of a the Instance Ids Instance Id_(n)specified CC_Entity for which the configured congestioncontrol/avoidance information is required to be provided.

The definitions for the parameters listed above are shown in Table 6,below. TABLE 8 Field Name Field Description CBS Committed Burst Size.This is used by the srTCM and trTCM algorithms to meter flows.cc_discard Specifies the algorithm used to discard packets. cc_entityIndicates the point of the network element where congestion controlshould operate (Port, Queue, Flow) cc_meter Specifies the algorithm usedto meter or color flows. cc_point Indicates whether congestion controlshould apply at the ingress entities or egress entities. WEST supportscongestion control only at ingress entities. C_(i) Coefficient ofincrease for BAT flows. CIR Committed Information Rate. This is used bythe srTCM and trTCM algorithms to meter flows. D_(i) Coefficient ofdecrease for BAT flows. EBS Excess Burst Size. This is used by the srTCMalgorithm to meter flows. Flowid A 16 bit flow identifier value. max_pMaximum probability of performing a RED drop. max_th Maximum queuethreshold for the RED algorithm. Max_(i) Maximum BAT bandwidth for flowi. min_th Minimum queue threshold for the RED algorithm. Min_(i) MinimumBAT bandwidth for flow i. PBS Peak Burst Size. This is a parameter usedby the trTCM algorithm to meter flows. PIR Peak Information Rate. Thisis a parameter used by the trTCM algorithm to meter flows. Port NumberIndicates the instance of the port type being operated upon. A maximumof 32 ports is supported. Shock Absorber Shock Absorber constant forBAT. constant w_qlen Weighting factor for calculating the average queuelength for the RED algorithm.

Thus, in a preferred embodiment, the generic APIs 150 include theconfigure, update, enable, disable, and list APIs. The five generic APIs150 preferably be used allow the congestion control application 112 tobe network processor independent and still control the potentiallyheterogeneous network processors 120, 130, and 140 in a networkprocessor specific manner. The congestion control application 112 is,therefore, simpler. As a result, it is significantly simpler to scalethe system 100, including adding new types of network processors. It isthus also easier to improve the performance of the system 100 by addingimproved network processors. In addition, the maintenance costs of thesystem 100 may be reduced due to the use of a simpler congestion controlapplication 112.

FIG. 5 is high-level flow chart of one embodiment of a method 210 inaccordance with the present invention for using a mechanism inaccordance with the present invention for managing congestion andcontrol behavior of network processors. For clarity, the method 210 isdescribed in conjunction with the system 100 depicted in FIG. 2.Referring to FIGS. 2 and 5, the method 210 presumes that the networkprocessors 120, 130, and 140, as well as the congestion controlapplication 112 have been configured for use with the generic APIs 112.For example, the congestion control application is network processorindependent and has a generic interface appropriate for use with thegeneric APIs 112.

A user, such as a network administrator, is allowed to input informationto manage the congestion control and avoidance behavior of the networkprocessors 120, 130, and 140 using the generic APIs 150 in a networkindependent manner, via step 212. In step 212, therefore, a user mightprovide the identification of the network processor desired to becontrolled, values of the appropriate parameters and flags, as well asother information used by the API(s) of the generic APIs being used. Thegeneric APIs 150 are then used to control the possibly heterogeneousnetwork processors 120, 130, and 140 in a network processor specificmanner, via step 214.

Using the system 100, the methods 200 and 210, and more particularly thegeneric APIs 150, the congestion control application 112 can be networkprocessor independent. Because of the use of the generic APIs, thecongestion control application 112 can still control the potentiallyheterogeneous network processors 120, 130, and 140 in a networkprocessor specific manner. As a result, the congestion controlapplication 112 need not include a separate set of APIs for each type ofnetwork processor 120, 130, and 140 used. The congestion controlapplication 112 is, therefore, simpler. As a result, it is significantlysimpler to scale the system 100, including adding new types of networkprocessors. It is thus also easier to improve the performance of thesystem 100 by adding improved network processors. In addition, themaintenance costs of the system 100 may be reduced due to the use of asimpler congestion control application 112.

A method and system has been disclosed for controlling the congestioncontrol and avoidance behavior of heterogeneous network processors usinga network processor independent control application. Software writtenaccording to the present invention is to be stored in some form ofcomputer-readable medium, such as memory, CD-ROM or transmitted over anetwork, and executed by a processor. Consequently, a computer-readablemedium is intended to include a computer readable signal which, forexample, may be transmitted over a network. Although the presentinvention has been described in accordance with the embodiments shown,one of ordinary skill in the art will readily recognize that there couldbe variations to the embodiments and those variations would be withinthe spirit and scope of the present invention. Accordingly, manymodifications may be made by one of ordinary skill in the art withoutdeparting from the spirit and scope of the appended claims.

1. A system for controlling congestion control and avoidance behavior ofa plurality of heterogeneous network processors in a network, thenetwork also including at least one host processor utilizing at leastone congestion control application, the system comprising: a pluralityof generic application program interfaces (APIs) communicating with theat least one congestion control application and the plurality ofheterogeneous network processors, the plurality of generic APIs forcommunicating with the at least one congestion control application inthe at least one host processor in a network processor independentmanner, the plurality of generic APIs managing the congestion controland avoidance behavior of the plurality of heterogeneous networkprocessors in a network processor specific manner; wherein the pluralityof generic APIs allow the at least one congestion control application tobe network processor independent and to manage the congestion controland avoidance behavior of the plurality of heterogeneous networkprocessors in the network processor specific manner.
 2. The system ofclaim 1 wherein the plurality of generic APIs are used by the at leastone congestion control application to determine at least one location ineach of the plurality of heterogeneous network processors the congestioncontrol and avoidance behavior is to be managed.
 3. The system of claim2 wherein the at least one location further includes an ingress portionand/or an egress portion of each of the plurality of heterogeneousnetwork processors.
 4. The system of claim 2 wherein the ingress portionfurther includes a plurality of ports, a plurality of receive queues,and a plurality of received flows.
 5. The system of claim 4 wherein theegress portion further includes a plurality of scheduler flows, aplurality of scheduler queues, a plurality of transmit queues, and theplurality of ports.
 6. The system of claim 2 wherein the plurality ofgeneric APIs are used by the at least one congestion control applicationto determine how the congestion control and avoidance behavior is to bemanaged at the at least one location in each of the plurality ofheterogeneous network processors.
 7. The system of claim 6 wherein theplurality of generic APIs determine at least one congestion controlalgorithm to be applied upon congestion at each of the at least onelocation in each of the plurality of heterogeneous network processors.8. The system of claim 1 wherein the plurality of generic APIs furtherreturn a null behavior for a portion of the plurality of heterogeneousnetwork processors in which a particular function of a particular API isnot supported.
 9. The system of claim 1 wherein the plurality of genericAPIs include a configure API, an update API, an enable API, a disableAPI, and a list API, the configure API allowing the at least onecongestion control application to configure the congestion control andavoidance behavior of each of the plurality of heterogeneous networkprocessors, the update API allowing the at least one congestion controlapplication to update the congestion control and avoidance behavior ofeach of the plurality of heterogeneous network processors, the enableAPI allowing the at least one congestion control application to enablethe congestion control and avoidance behavior of each of the pluralityof heterogeneous network processors, the disable API allowing the atleast one congestion control application to disable the congestioncontrol and avoidance behavior of each of the plurality of heterogeneousnetwork processors, and the list API allowing the at least onecongestion control application to obtain a list of the congestioncontrol and avoidance behavior of each of the plurality of heterogeneousnetwork processors
 10. A computer-readable medium including a programfor controlling congestion control and avoidance behavior of a pluralityof heterogeneous network processors in a network, the network alsoincluding at least one host processor utilizing at least one congestioncontrol application, the program comprising instructions for:implementing a plurality of generic application program interfaces(APIs) communicating with the at least one congestion controlapplication and the plurality of heterogeneous network processors, theplurality of generic APIs for communicating with the at least onecongestion control application in the at least one host processor in anetwork processor independent manner, the plurality of generic APIsmanaging the congestion control and avoidance behavior of the pluralityof heterogeneous network processors in a network processor specificmanner; wherein the plurality of generic APIs allow the at least onecongestion control application to be network processor independent andto manage the congestion control and avoidance behavior of the pluralityof heterogeneous network processors in the network processor specificmanner.
 11. The computer-readable medium of claim 10 wherein theplurality of generic APIs are used by the at least one congestioncontrol application to determine at least one location in each of theplurality of heterogeneous network processors where the congestioncontrol and avoidance behavior is to be managed.
 12. Thecomputer-readable medium of claim 11 wherein the at least one locationfurther includes an ingress portion and/or an egress portion of each ofthe plurality of heterogeneous network processors.
 13. Thecomputer-readable medium of claim 11 wherein the ingress portion furtherincludes a plurality of ports, a plurality of receive queues, and aplurality of received flows.
 14. The computer-readable medium of claim13 wherein the egress portion further includes a plurality of schedulerflows, a plurality of scheduler queues, a plurality of transmit queues,and the plurality of ports.
 15. The computer-readable medium of claim 11wherein the plurality of generic APIs are used by the at least onecongestion control application to determine how the congestion controland avoidance behavior is to be managed at the at least one location ineach of the plurality of heterogeneous network processors.
 16. Thecomputer-readable medium of claim 15 wherein the plurality of genericAPIs determine at least one congestion control algorithm to be appliedupon congestion to the at least one location in each of the plurality ofheterogeneous network processors.
 17. The computer-readable medium ofclaim 10 wherein the plurality of generic APIs further return a nullbehavior for a portion of the plurality of heterogeneous networkprocessors in which a particular function of a particular API is notsupported.
 18. The computer-readable medium of claim 10 wherein theplurality of generic APIs include a configure API, an update API, anenable API, a disable API, and a list API, the configure API allowingthe at least one congestion control application to configure thecongestion control and avoidance behavior of each of the plurality ofheterogeneous network processors, the update API allowing the at leastone congestion control application to update the congestion control andavoidance behavior of each of the plurality of heterogeneous networkprocessors, the enable API allowing the at least one congestion controlapplication to enable the congestion control and avoidance behavior ofeach of the plurality of heterogeneous network processors, the disableAPI allowing the at least one congestion control application to disablethe congestion control and avoidance behavior of each of the pluralityof heterogeneous network processors, and the list API allowing the atleast one congestion control application to obtain a list of thecongestion control and avoidance behavior of each of the plurality ofheterogeneous network processors.
 19. A method for controllingcongestion control and avoidance behavior of a plurality ofheterogeneous network processors in a network, the network alsoincluding at least one host processor utilizing at least one congestioncontrol application, the method comprising: (a) abstracting thecongestion control and avoidance behavior of each of the plurality ofheterogeneous network processors; (b) providing a plurality of genericapplication program interfaces (APIs) based on the abstraction, theplurality of generic APIs communicating with the at least one congestioncontrol application and the plurality of heterogeneous networkprocessors, the plurality of generic APIs for communicating with the atleast one congestion control application in the at least one hostprocessor in a network processor independent manner, the plurality ofgeneric APIs managing the congestion control and avoidance behavior ofthe plurality of heterogeneous network processors in a network processorspecific manner; wherein the plurality of generic APIs allow the atleast one congestion control application to be network processorindependent and to manage the congestion control and avoidance behaviorof the plurality of heterogeneous network processors in the networkprocessor specific manner.
 20. The method of claim 19 wherein theplurality of generic APIs are used by the at least one congestioncontrol application to determine at least one location in each of theplurality of heterogeneous network processors where the congestioncontrol and avoidance behavior is to be managed.
 21. The method of claim20 wherein the at least one location further includes an ingress portionand/or an egress portion of each of the plurality of heterogeneousnetwork processors.
 22. The method of claim 20 wherein the ingressportion further includes a plurality of ports, a plurality of receivequeues, and a plurality of received flows.
 23. The method of claim 22wherein the egress portion further includes a plurality of schedulerflows, a plurality of scheduler queues, a plurality of transmit queues,and the plurality of ports.
 24. The method of claim 22 wherein theplurality of generic APIs are used by the at least one congestioncontrol application to determine how the congestion control andavoidance behavior is to be managed at the at least one location in eachof the plurality of heterogeneous network processors.
 25. The method ofclaim 19 wherein the API providing step (b) further includes the stepof: (b1) providing a portion of the plurality of generic APIs that arecapable of setting at least one congestion control algorithm to beapplied upon congestion at each of at least one location in each of theplurality of heterogeneous network processors.
 26. The method of claim19 wherein the API providing step (b) further includes the step of: (b1)ensuring that the plurality of generic APIs return a null behavior for aportion of the plurality of heterogeneous network processors in which aparticular function of a particular API is not supported.
 27. The methodof claim 19 wherein API providing step (b) further includes the step of:(b1) providing a configure API, an update API, an enable API, a disableAPI, and a list API, the configure API allowing the at least onecongestion control application to configure the congestion control andavoidance behavior of each of the plurality of heterogeneous networkprocessors, the update API allowing the at least one congestion controlapplication to update the congestion control and avoidance behavior ofeach of the plurality of heterogeneous network processors, the enableAPI allowing the at least one congestion control application to enablethe congestion control and avoidance behavior of each of the pluralityof heterogeneous network processors, the disable API allowing the atleast one congestion control application to disable the congestioncontrol and avoidance behavior of each of the plurality of heterogeneousnetwork processors, and the list API allowing the at least onecongestion control application to obtain a list of the congestioncontrol and avoidance behavior of each of the plurality of heterogeneousnetwork processors.